1. Field of Invention
The present invention relates to printing over a TCP/IP network. More specifically, it relates to printing in a point-of-sale (POS) network.
2. Description of Related Art
Network printing refers to the sharing of printing resources on a computer network. An early application of network printing is the print server, or printer server, as illustrated in FIG. 1. A printer server 11 is a device that connects a client computer 13a with a printer 15a on a common computer network 17. That is, client computer 13a sends a print job to printer server 11; printer server 11 receives and holds (i.e., spools) the print job; and when printer 15a becomes available, printer server 11 sends the held print job to printer 15a for printing. It is to be understood that printer sever 11 may manage multiple print jobs from multiple client computers 13a through 13n among multiple printers 15a through 15i, and that the computer network may including both wired and wireless communication links. Individual printers 15a through 15i may be local printers and/or network printers, and may be connected directly to print server 11 via a direct cable connection (such as a by a parallel cable, USB cable, proprietary cable, etc.) or by a wired network connection (IEEE 802.11 on standardized network category cable (i.e., CAT 5, 5e, 6), etc.) or by a wireless network connection (IEEE 802.11 a/b/g/n, etc.) or by another known wireless communication link (Bluetooth, HomeRF, HyperLan, etc.)
Printer server 11 is responsible for queuing (i.e., spooling) print jobs while it waits for a target printer to become available. It may also be responsible for re-ordering or deleting print jobs in its queue, keeping track of printer activity (such as the number of pages printed, the time of printing, etc.). As a result, printer server 11 generally supports multiple industry standards and/or proprietary printing protocols, and thus may also include printer drivers for each printer under its management. Although printer servers are well suited for private networks, as the industry has moved toward using the prolific internet protocol TCP/IP for both public and private networks, it has become desirable to incorporate printing capabilities in public networks through internet interfaces.
The “web browser” is a popular internet interface (commonly used on the Worldwide Web, i.e., WWW or Internet), which displays “web pages” based on the HyperText Markup Language (HTML). A markup language is a text-based language system that uses “tags” to provide machine-executable instructions in a textual format that is legible by a human reader. For example, tags may instruct the web browser about how to format information for display on a web page (i.e., how to display the web page information on a display screen), or to specify a desired executable function.
As the Internet grew, it became desirable to provide more functionality than was available on early versions of HTML. To address this need, the Java language was adapted to provide fully contained machine code that could be embedded within an HTML web page. These small applications became known as applets. Java is a full-feature, object oriented programming (i.e., OOP) language used in many applications, such as in control applications for small devices and appliances.
Companies that created Java applications to control their devices wanted to ease adoption of their devices by third-party manufactures without releasing proprietary information regarding the control programs of their devices. This was achieved by the use of application program interface (API) libraries that provided simplified interfaces to their control applications, and thereby simplified the adoption of their control programs by third-party manufacturers. Basically, an API is a set of common code pieces with specified input and output requirements, such as are found in objects or classes in OOP languages, and which provide an interface to a coded application. In this manner, a user does not need to re-code a specific software tool or even to know how the software tool is coded. The user merely needs to know how to invoke the software tool, pass it any specified parameters, let it execute the desired function, and receive any specified output. Although Java made web pages more dynamic, Java applications (and applets) are compiled programs that are provided in machine code, not script, and are therefore not readily legible by a human user. Thus, the use of applets reduced the readability of HTML code.
JavaScript, which provides some of the dynamic capabilities of Java in a script-language form, addresses this issue. Since JavaScript is a script language, HTML can execute JavaScript code without the JavaScript code being pre-processed (i.e., compiled), and thus it remains in a script (i.e., textual) form. Like Java applets, JavaScript may be embedded within an HTML web page, and the web browser will execute it when the HTML web page is downloaded or in response to a triggering event. JavaScript permits a web page to dynamically modify its content or add content to a current web page or send content from that web page. JavaScript, and other script languages, permit web pages to become more interactive by providing a bridge between the web browser and the operating system on which the web browser is running. This permits a web page to incorporate information from the user's local device environment, such the device's location and other user information that the web browser and/or operating system deem safe to provide to the web page.
With the adoption of JavaScript, software developers began providing complete script applications designed to execute specific tasks. When these script applications are packaged as a unit for insertion into a web page, they are sometimes termed “widgets”. Since each widget is as a complete script code, it may have a set of expected inputs and a list of possible outputs, in a manner similar to how inputs and outputs are used in Java applets. As a result, APIs have also been developed for script codes. For example, a company may produce a library of script codes to operate with a specific device and provide a list of API's that facilitate the integration of their script codes into a third party developer's code. Thus, the third party developer does not need to understand how the company's device works or know how to program it; the third party developer can quickly insert control of the company's device by using their provided API's and/or widgets (i.e., script codes).
This leads to the topic of printing from a web browser, i.e., HTML printing. Most web browsers provide a print function on their toolbar (i.e., a visual list of selectable “software-buttons” for invoking different tasks), and when a user selects this print function, the web browser accesses the local device's printer through the print APIs of the local device's operating system. That is, the web browser does not know what type of printing capabilities are available to the device on which it is running, if any, and the operating system does not share this information with the web browser for security reasons. Thus, in order for the web browser to print, it must pass this function request to the operating system, which it may do by calling up the operating system's print interface.
Consequently, printing from a webpage requires going through a printer dialogue box, as is illustrated in FIG. 2. The printer dialogue box 19 provides printer information and provides options for a user to select from to format the printed document. These options are determined from the printer's capabilities, which are in turn provided by the printer driver. For example, printer dialogue box 19 may provide a printer-select option 21 to select among multiple available printers. Boxes 21a through 21c may provide information about the selected printer, such as its status, type and location, respectively. Other options may include a choice of printing in black-and-white or color, as indicated by selection button 23. A user may also enter a range of pages to be printed, and/or select a paper type or paper orientation, as indicated by selection buttons 25 and 27.
Some web browsers may provide a quick-print option wherein a currently displayed web page is sent for printing without the use of a printer dialogue box by instead sending the printing request to a default printer and accepting all the printer's default settings. This request is sent to the local operating system's print API, and if it supports quick printing and it has default print and its default settings assigned, then it will accept the webpage for printing. Unfortunately, the entire web page is sent for printing. Thus, web page developers have no control over how, or what part of, a web page is printed, or what material, in general, is printed. The web page developers also do not know what printers are available or their print-capabilities, nor do the web developers know what the individual printer's default settings might be. To summarize, the web browser goes through the local device's operating system (OS), and assumes that on the local OS will access the appropriate printer driver.
The XML printer has been developed to reduce the reliability on printer drivers, and to have more control over the formatting of printed documents. The XML printer is not limited to web pages, and can serve as a local virtual printer. That is, it responds to a print request as if it were a physical printer, but instead of producing a physical printed document, it produces a script-language description of how the printed document should look. This is similar to how the HTML script language is used to define the look and format of a web page on a display screen. This script-language description can then be sent to a physical printer that supports XML printing to produce a physical print-out. XML printers are typically used to maintain consistency of printing across different platforms and document formats. For example, an XML print document file would assure that a document prepared in Microsoft Word™ would print the same as the same document prepared in Adobe Acrobat™.
Thus, if one has an XML print document file and a printer (or printer driver) capable of reading XML print document files, one may send the XML print document file to the printer without need of printer driver requirements. The printer (or its printer driver) would read the scripted description of how the document should look, and generate its own print image for printing. Although the XML printer reduces the reliance on printer drivers, and thus facilitates printing on a network, it does not provide any additional printing control to the web page developer. That is, the web page developer still cannot control printing from within a script application, or widget, but instead relies on the web browser as a print interface.
JavaScript does not provide any assistance in this matter. Although the web browser may interface with the local operating system to access the local printer's API or call upon an XML printer to create an XML print document, for security reasons the web browser does not share this information with its Java scripts. That is, the job of the JavaScript is traditionally to define information on a web page and to provide dynamic functionality; it is not the Java script's job to print documents. It is the web browser's job to control the print function, and thus it does not share this control with internal script applications. As a result, heretofore a JavaScript application cannot directly control a printer. It must instead request that the web browser make a print request, which in turn relays the request to the local OS, which then calls up the print dialogue box to setup a local/network printer (real or virtual).
In spite of these difficulties, strides have been made toward providing web-printing, i.e., printing over the Internet. For example, the Internet Printing Protocol (IPP) provides a standard network protocol for remote printing over the internet, which removes the need for individual print drivers on each user's machine. IPP provides control over various printing needs, such as managing print jobs, media size, resolution, etc, and is intended to provide users with similar methods and operations as if the printer were local. Basically, IPP is a collection of open standards that define a network printing protocol, and if a printer vendor has adopted this standard, then IPP allows a user to interact with that vendor's printer in real-time in order to find out about the printer's capabilities, inquire about the status of a print job or cancel a print job that has been submitted. As in the case of a local printer, this dialogue would be through a printer dialogue box.
Another approach toward providing internet printing is known as Google Cloud Printing™, or GCP. This is a service provided by Google™ Corp., and it basically permits developers to incorporate printing capabilities into their web pages and services by sending print requests to Google Corp, letting Google Corp. prepare print jobs (limited to PDF print jobs) and forward them to a user's pre-registered printer. Google™ Corp. provides an API to permit developers to quickly insert the required code, and it uses a standard printing dialogue box to create and submit PDF print jobs. As it would be understood, this means that Google has access to all documents to be printed, which raises questions of security and privacy for users. It is further note that another limitation of this service is that it requires that the document-to-be-printed already be on the web, and not just on the user's computer. Thus, the service cannot be used to print locally generated documents that are not on the web.
What is needed is a way to increase a user's control over printing from within a web browser.
It is further preferred that developer have direct access to, and control over, a printer directly through a script application, such as a JavaScript widget, without having to send a print request to a local web browser.
It also desired that a script application within web page be able to directly generate and format the information to be printed, and to send the information directly to a printer without necessitating a print dialogue box, or being limited by the content within the web page.
It is further desired that a user have direct web printing capabilities without depending upon any third party entity to manage print jobs.